Investigate, Review, Reflect, Act

Investigate your organization's metrics#

Find out—if you don’t know already—what metrics are in place for your organization. Ask your manager or your skip-level manager (your boss’s boss) for whatever details can be shared with you. Next, ask somebody in a non-software part of the organization, such as HR, finance, sales, or marketing, what their metrics are.

Reflect on your past metrics#

Spend a few moments in your notes and write down software metrics that you personally have been held to over the years. With the clarity of hindsight, make a note of the pros and cons of each of these metrics. Consider the following questions:

• Were they all easily measured?

• Were some too subjective?

• How could the metric be abused? If your entire salary was dependent on this one metric, how would you make the most money for the least work?

• If that metric were abused, how badly would the team/project/company be damaged?

Research other metrics#

Enter “software development metrics” into your favorite search engine, and capture all the different metrics that come back. Which of these seem like individual metrics, which are team metrics, and which are ripe for abuse?

Analyze trends#

If you have a tool for analyzing project metrics, run some stock reports on the work done by your team. What trends do you notice? Are those trends team-wide? Now compare the dates of some of those trends with the notes in your personal notebook—do the trends correlate in some way? Can you spot “hot zones” where two things seem to be happening together? Perhaps code reviews got a lot shorter during one sprint, and the release had to be rolled back. Or perhaps every time the code reviews get shorter, the release has fewer bugs. Don’t analyze; take note of the trends.